TDD와 XP

Test-driven development and Extreme programming

How does TDD relate to the practices of Extreme Programming?

Some reviewers of this book were concerned that by my writing a book exclusively about TDD, folks will take it as an excuse to ignore the rest of the advice in Extreme Programming (XP). For example, if you test drive, do you still need to pair? Here is a brief summary of how the rest of XP enhances TDD, and TDD enhances the rest of XP.

Pairing: The tests you write in TDD are excellent conversation pieces when you are pairing. The problem you avoid is that of the partners not agreeing on what problem they are solving, even though they are trying to work on the same code. This sounds crazy, but it happens all the time, especially when you are learning to pair with someone. Pairing enhances TDD by giving you a fresh mind to take over when you get tired. TDD’s rhythm can suck you in, and lead you to continue to program even when you’re tired. Your partner, however, is ready to take the keyboard when you flag.

Work fresh: On a related note, XP advises you to work when you are fresh and stop when you are tired. When you can’t get that next test to work, or those two tests to work together, it’s time for a break. Uncle Bob Martin and I were working on a line break algorithm once, and we just couldn’t get it to work. We struggled in frustration for a few minutes, but it was obvious we weren’t making progress, so we stopped.

Continuous integration: The tests make an excellent resource, enabling you to integrate more often. You get another test working and the duplication removed, and you check in. The cycle can be 15 to 30 minutes instead of the 1 to 2 hours that I usually shoot for. This may be part of the key to having larger teams of programmers on the same code base. As Bill Wake says, “An n2 problem is not a problem if n is always 1.”

Simple design: By coding only what you need for the tests and removing all duplication, you automatically get a design that is perfectly adapted to the current requirements and equally prepared for all future stories. The mind-set that you are looking for just enough design to have the perfect architecture for the current system also makes writing the tests easier.

Refactoring: The Remove Duplication rule is another way of saying “refactoring.” But the tests give you confidence that your larger refactorings haven’t changed the behavior of the system. The higher your confidence, the more aggressive you will be in trying large-scale refactorings that extend the life of your system. By refactoring, you make writing the next round of tests that much easier.

Continuous delivery: If TDD tests really do improve the MTBF of your system (a contention you will have to verify for yourself), then you can put code into production much more often without disrupting customers. Gareth Reeves makes the analogy to day trading. In day trading, you close out your positions every night, because you don’t take risk around that which you aren’t managing. In programming, you like all of your changes in production because you don’t want code around that you aren’t receiving concrete feedback on.

—Chapter 32, Test-driven development: by example